软件测试灵魂三问，如何怼回去？
（的确有一个错别字，测试人员一眼就能发现）
这是上周参加一个闭门小型质量创新研讨会议所看到的一个slide，我拍了之后，发到朋友圈，很快被疯狂转发、风靡整个测试界，因为大家感同身受，太有共鸣了！
灵魂三问：
有朋友说：
对测试新人则是“惊魂三问”！
如果老板也这么问，更惊魂！
如果是开发人员问测试人员，则是“甩锅三问”
如果是测试人员自问，倒是反思，不是坏事！
也有朋友说，问了几万遍，就是没有答案
学生对我说，来一个"灵魂三怼"
我觉得不会太难，因为一年前我还回答比这更难的问题：
要么先看看网友如何怼回去的？
by @混子
如果是研发问，直接怼回去：
1. 这么简单功能也出错？
2. 研发怎么开发的，会不会开发？
3. 研发能不能快点，为什么最后才给我们打包？
如果是领导问，马上认错：
对不起！对不起！对不起！
（注：似乎怼得不错，但开发一定会再怼回来，1. 功能不简单啊，如果功能不出错，还要你们测试干什么？2.你来开发、写给我看看？......可能会引来一场格斗）
by @结婚兔子
具体问题具体分析吧：
1. 复盘下为什么没有测出来？是开发单元测试覆盖度不够，用例覆盖度不够，还是事实上就是难以覆盖到，之后改进。
2. 把测试流程分享出来，邀请业务方、研发、测试等等相关人员，一起完善。
3. 从流程下手，需求开发测试都要排期，测试排期要有“底线”.实在不行，只能用老办法，要么砍掉不核心的需求，要么延期；另一方面，做测试提效，自动化测试、提测质量准入、测试左移右移那一套都用上。
（注：这样的态度很好，善于反思，从流程、技术、人等找根因，力求立行立改、息事宁人，但不怼回去，长期下去，地位会不会越来越低？ ）
by @BNN
1. 分析缺陷产生原因、复现条件：测试环境能否复现？线上环境为什么没有复现？没有复现影响多大？—— 如果是漏测，那就得认；
2. 摆事实：讲清测试方案、设计、方法，确认这个方案当时有没有获得一致评审通过？如果当时已经通过了，那就是大家的锅；如果这些没做，那测试当然就负主要责任；
3. 看看是不是测试阶段总在做一些验收性的测试？如果是，验收性测试本身就比较耗时间，测试时间不足，测试的深度自然也不足；如果本身不是做一些验收性的测试，测试能够提前介入，一般不会“最后才报 Bug”，这里只需要列举“提前”报的 Bug。
（注：和第二个差不多，首先从自身找原因，进行根因分析，case by case， 摆事实、讲道理，解决问题是硬道理 ）
by @Ouroboros
看情况吧。如果是自己问自己，那么就好好分析下。
如果是开发要甩锅，那么就按 @混子 兄弟说的怼回去。
如果是领导问到了，那就是时间紧、技术债多、开发不自测、基础设施差、沉淀差、产品瞎B改，再道个歉，许诺个美好的未来。
最后说要用 TDD，需要一波 Money 或者其它激励，来偿还技术债，比如让开发自测需要推动，基础设施需要组织人做，都需要钱💰和资源。嗯，这么看，好像还是个增收途径。
（注：到后面跑题了 ）
by TW 余同学：
这个问题一定很隐蔽吧？不然怎么会单元测试没发现，自测没发现，集成测试也没发现，要不要一起分析问题的原因以便日后改进 这部分我上下文不足，可以和你pair一起测吗？ 如果你自己的代码有足够的信心，不给测试留时间也可以，相信你可以控制好自己的代码质量
（注：第一个问题怼得挺好。第3个回答，显得测试是多余的？ ）
by 盘古 王同学：
目前看到的，我比较赞同评论是：就在大家相互扯皮的时候，鹅厂又发钱了！微信支付团队拿到2019年公司创始人奖，奖金2个亿，这还不包括年终奖（年终奖10个月起）。腾讯云完成100亿营收，团队每人阳光普照，一人一部iPhone 11 Pro。 我们认真思考一下，快节奏的今天，还拿出这些东西聊个昏天暗地，从本质上其实就在浪费时间，可以说这些都不是问题，是结果。 原因太多了，大家都知道，但提出这些话题的意义是什么呢？如果一个测试团队还在这些东西上面浪费时间，那么对不起，我们已经输了，对手的唯一目标是推掉我方水晶！我们的目标在谁来背锅。如果这么几句嘲讽话语就逼疯测试，那么我们真的应该反省一下，自己有多脆弱不堪，测试也好开发也罢，共同目标是赢这一局，不是故步自封撇清自己！
最后一个同学，是不是说得很好？我把这段话从我的朋友圈搬到这里，对我写这篇文章不利啊，因为她已经批评我们“还拿出这些东西聊个昏天暗地，从本质上其实就在浪费时间”，那为什么还搬过来了？因为有道理。
我们再回头看那“灵魂三问”：
第1问，不管是开发问还是老板问，不管是为了甩锅还是追究责任而来，都是需要回答的问题——产品上线后有遗漏的Bug，就需要问“为什么”？而且不只一个“为什么？”，按照根因分析方法，最多会问五个“为什么？”，“为什么这个 Bug 测不出来？” 这是第一问，答案可能是：
没有测试用例，会继续问：为什么没有测试用例（案例）？
有测试用例，没有执行或环境不对，会继续问：为什么没有执行（或环境为什么不对）？
只有这样不断深挖下去，才有可能找到根本原因在流程、在开发身上。不问为什么，是没办法让开发和领导知道他们自身存在的问题。虽然我们知道：
测试不能穷尽的
一般软件测试只是样本试验不是数学证明
开发写出的Bug越多，测试漏掉的Bug越多
这些只是道理，怼起来，力量不够。用具体的case或事实来说明问题更好、更有力。如果上面五个“为什么”追究下去，追到测试自身问题，那也说明测试自己没做好，需要改善。
第2问，的确说明问者带有情绪了，是第一问经常被问住了？还是产品上线后问题比较多？如果是前者，回到“第1问”；如果是后者，这时可以用“开发写出的Bug越多，测试漏掉的Bug也越多”来怼，最好用数据来说明，例如：
开发写出1000个缺陷，测试发现Bug的能力是98%，那么漏掉20个Bug
开发写出100个缺陷，测试发现Bug的能力还是98%，那么只漏掉2个Bug
这种带着情绪的问，如上面王同学说，也可以置之不理。如果对自身能力比较自信的，可以怼过去：
开发有没有做单元测试？有没有code review？
咱们看看哪些缺陷是可以通过单元测试、code review能发现的？
要不要我们一个一个bug过，看看这些bug究竟怎样逃过一关又一关的？
你们怎么写出这么多缺陷？怎么写的代码？
这么多缺陷，不都是开发写出来的？
难道不知道 “质量是构建出来的、不是测试测出来的” 吗？
咱们换一个位置，你来测，我来写代码，如何？
有实力，才能怼😄
第3问，这个问题要一分为二，如果之前前期发现的缺陷少，后期发现的缺陷多，测试的确要反思，没有很好地采用“基于风险的测试策略”。如果前期也报了比较多问题，但最后也报了几个缺陷，这比较正常。因为从目前现实情况看，测试常常是瓶颈，这是现实，因为测试人员少，开发：测试比常常是4:1、5:1或更高。其实，测试工作量没这么少，测试人员不仅要做新改动的测试，还要做回归测试，更何况许多开发没做好单元测试和code review，如果再加上缺乏代码规范、代码质量不高，只能是恶性循环，没有“银弹”能解决这样的问题。
测试是瓶颈，没办法，因为公司的投入就少、开发测试人员配比不合理
咱们换一个位置，你来测，我来写代码，如何？
开发和测试是一个团队，只有同心协力，才能取得成功。有时“为什么”（如第1问）还是需要问的，只是更应该自问，不断反省，才能提高。而且自己有实力、具备有效的测试方法、测试策略，能够讲清测试故事、说明白自己所做的测试工作，就不怕问！
之后需要写一篇“质量是构建的”，虽然每个人都知道。
如果没完成了“灵魂三怼”，就算抛砖引玉，欢迎大家留言继续怼😄
参考：